-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Don’t unconditionally convert config keys to kebab-case
#19337
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughThis PR preserves camelCase theme keys from JS configs and plugins. Tests and snapshots were updated to use camelCase tokens and class names. The keyPathToCssProperty transformation was changed to conditionally kebab-case path segments (first namespace part, tuple-nested keys indicated by leading '-', and the special Pre-merge checks✅ Passed checks (5 passed)
Comment |
RobinMalfait
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes sense that if your own names for values were described in camelCase that it should stay as camelCase instead of being converted to kebab-case.
This could be a breaking change technically, but then you already had a breaking change in the first place (because your camelCase name was converted to a kebab-case name).
If it causes too much trouble for people, we could enable both (and probably show a warning that you have a casing mismatch and that you should either convert the source or the usages).
|
Yeah, I think if this causes issues then we can try to do something similar to #18115 in addition to this PR to address that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
CHANGELOG.md (1)
17-17: Clarify exceptions and cross-link issues in the changelog entry.Spell out the kebab-case exceptions (top-level theme keys and tuple object keys) and link the fixed issues for traceability.
- - Preserve case of theme keys from JS configs and plugins ([#19337](https://github.com/tailwindlabs/tailwindcss/pull/19337)) + - Preserve case of theme keys from JS configs and plugins, except: + - top‑level `theme` keys (still kebab‑cased), and + - tuple object keys used as CSS property names (still kebab‑cased, e.g., `lineHeight` → `line-height`) + ([#19337](https://github.com/tailwindlabs/tailwindcss/pull/19337), fixes [#18114](https://github.com/tailwindlabs/tailwindcss/issues/18114), closes [#18115](https://github.com/tailwindlabs/tailwindcss/issues/18115))
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
CHANGELOG.md(1 hunks)integrations/upgrade/js-config.test.ts(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- integrations/upgrade/js-config.test.ts
Fixes #18114
Closes #18115
This PR changes JS config handling such that we always preserve casing for theme keys (when possible).
Now there are two exceptions to this rule:
All of our internal plugins look for kebab-case keys. So, for example, take the path
backgroundColor.red.500. This must translate to--background-color-red-500. But if you had something likebackgroundColor.lightBlueit would be perfectly fine for that to translate to--background-color-lightBlueinternally (and thus the utility be written asbg-lightBlue.These keys are converted to "nested" key syntax internally and typtically represent CSS property names.
For example:
The
lineHeightkey here must be converted toline-heightbecause it represents a CSS property name. The theme key that represents this value is--text-xs--line-height. The same situation applies for thefontVariationSettingswhere the theme key is--font-sans--font-variation-settings.